Related issues

• Builds on the Studio Web foundation (Studio Web: run the portable UI in a browser via a web connector and a CLI web-server command #3816, merged). Continues the broader exploration in Studio Web (SecEx): functional sandbox sites + live client-side preview [PoC] #3746.

How AI was used in this PR

The code and this PR description were drafted with Claude Code under close direction, extracting and adapting the live preview from the exploration onto the merged foundation. I reviewed the diff, and every verification step (typecheck across all workspaces, lint, the full apps/ui test suite — 233 tests, both UI build targets, and a live smoke test of the new endpoint + workspace binding) was run on this branch.

Proposed Changes

#3816 put Studio's portable renderer in a browser talking to a local studio web-server, but you couldn't see anything the agent did. This increment makes Studio Web visibly build a site: ask the agent to create something and watch it render, live, in the same browser tab.

Two things land together because the preview needs both:

• A place for the agent to build. Each session now gets its own git-backed workspace — the cloud analog of Studio App's local site, and a concrete answer to "where does the agent build / where does work persist." This is the git-as-project-container model: the workspace is the durable project, git status is the change set, and a later git push is the publish/deploy step (a follow-up — this PR only reads the workspace for preview).
• A live preview of it. The browser overlays the workspace's files onto a WordPress Playground running entirely client-side (PHP-WASM). After each agent turn the backend signals the browser, which re-fetches and re-renders. There's no server-side site serving: the preview runs on the visitor's CPU and costs the backend nothing, so it scales for free.

The boundary stays clean: the agent and workspace live behind the same connector→web-server HTTP/SSE contract from #3816 (a new /api/sessions/:id/site-files endpoint + a preview signal). The browser holds no tokens and talks only to that backend. Desktop is untouched: the IPC connector returns no workspace files, so the desktop app keeps rendering its own server-backed SitePreview.

Testing Instructions

1. Check out this branch and npm install.
2. Sign in so the agent can work: node apps/cli/dist/cli/main.mjs auth login.
3. Build the web UI once: npm run build:web --workspace=apps/ui.
4. Start the server: node apps/cli/dist/cli/main.mjs web-server and open http://localhost:8088.
5. Start a new session and ask the agent to build something (e.g. "Create a simple portfolio theme").
6. When the turn finishes, open the preview panel: the site renders live in a client-side Playground and refreshes on each subsequent turn.
7. Confirm desktop is unaffected: npm start behaves exactly as before (no live-Playground panel; the normal site preview is unchanged).

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?